Yep. Sure. No, this is the third slide. Sure. Um. You're participant s Two? Do you want the mouse, or do you want me to Mm-hmm. Do you have any preconceived ideas in terms of materials? 'Cause, for example, in the unbreakable thing, doing something plastic would be harder, whereas having something like, I dunno, steel or titanium isn't really economically viable. Yeah. Yeah. Sure, yeah. No, I just wondering whether that you had any sort of Yeah. The marketing comes out. That's Christine's. And that's mine, I think. In modified. S 'scuse me for one sec. Hmm. It seems also like with the speech recognition, yeah, it's a great feature, but if you're watching T_V_, there's a lot of ambient sound, and it's words. It's not just, you know, noises like something hitting. It's actual speech, so then you have to make sure that the speech recognizer is good enough to filter out the T_V_ speech, and the the user's speech. Otherwise, you can say remote. But if someone on the screen is saying the same thing, all of a sudden, you have someone in a movie saying off and your screen dies, because they've triggered the remote control and it's turned off your T_V_. So, I think if we can find a speech recognizer that can handle those types of problems, then yeah, it'd be a really good marketing gimmick. But, I think we seriously need to consider how that would impact the situation. Mm-hmm. Yeah. Yeah. Mm-hmm. Mm-hmm. Oh yeah. Yeah. No, I think it's a great idea if we can design it to to suit those requirements. Yeah. Um well, I mean, maybe if I go through my presentation, you can sort of see what the user perspective is, and how it ties into the other two comments. Mm participant three. Nope, here Good. Thanks. Yeah, and that's fine. Okay. So, basically, the method that we usually use in the user interface design is that we need to look at what people like and what people don't like about existing products. So, in our case, existing remote controls. And then, what the good ideas are, and what the bad ideas are, and why they're bad and good, which isn't always as obvious. We seem to have intuitions about why things are good or things are bad, but when you look, technically, at how it works, sometimes that's not the case. Then we need to decide what functionalities we really want to keep, 'cause that'll feed into both Ed's work and Christine's work. Um and then what the remote control should look like, obviously, once we've got a good idea of what the functionalities are. So, in terms of the functionalities that we need, you obviously need to be able to turn the T_V_ on and off. You need to change channels, both by directly going to a specific channel or by channel surfing. You need to be able to control the volume and then control any menus on the T_V_ to regulate contrast or whatever. So, the problems that people have expressed is that there's too many buttons on remote controls, in general. The buttons it's not clear what they're supposed to do. Um often, you need to know specific button sequences to get certain functionalities done, um which you don't necessarily always remember, especially if it's a functionality that you don't use very often. And that the buttons are too small. So, here we've got two examples where here on the left-hand side, you can see a remote control that has lots and lots of buttons. The buttons, in a lot of cases, are tiny. Um they're hard to see, and okay, they're labelled, but the labels don't necessarily tell you too much. Whereas, on the other side, you have a much simpler remote control that I think basically has the minimum functionalities that are needed. And it sort of looks simpler and just less imposing when you first look at it. So, I would be inclined to go sort of towards this, in terms of design, rather than this. And if there's specific functionalities that require more buttons, then we can figure out how to do it with existing um buttons. So my personal preferences are to keep the number of buttons to a limit, or to a minimum, sorry, make frequently used buttons bigger and more strategically placed, so like the on button being really obvious one, the channel changing and the volume, and to keep the design basically sleek and simple. Which, I think ties into what Christine and Ed have both said fairly reasonably. Um so, that's pretty much it, an I don't know if you guys have any questions or Yep. Yes, that's true. Yeah. Yeah. Mm-hmm. Yeah. Yeah. Oh, that's definitely a very important factor, especially to users who are gonna be buying the thing and then using it almost on an daily basis in a lot of cases, I think. Oh Should we maybe make a decision about what features we actually want to include, 'cause we've thrown a lot of features onto the table, but do we actually want to incorporate all of them, or have we missed anything? Sure. Mm-hmm. I thought No, I I'm just thinking in terms of time, like if Yes, now I'm objecting. No, I mean, I was just thinking is it really practical to start designing something with features that we're just gonna end up throwing away? I mean, it takes a lot of time and effort for everyone to consider different features, um and s if we spend that time and effort on features that we're not gonna use, maybe it's better to spend it on the f thinking more about features that we actually do want, but I guess Sure. Yeah. Yeah. Sure. Okay.